Propagating a “health” status over an entire database of entities is a time-consuming, deadlock-prone, resource-intensive operation. As an example, when a fibre-channel switch port changes state from nominal to critical, the health status of the owning switch should likely be modified to some marginal status to indicate a problem within the switch. Likewise, once this switch's health status has changed to marginal, the status for the entire fibre-channel fabric that owns the individual switch should be modified as well. This changing of the health status of one entity can produce a “waterfall” or “cascading” effect to other related entities.
This problem is not isolated to SAN (Storage Area Network) or fibre-channel devices, and could apply to any systems management software which stores any kind of “health” status, in which that health is based, in part, on the subordinate entities related to it. Another example is a monitored application which quits unexpectedly. In this situation the application's status changes to critical which in fact causes application server's status to change to marginal, which will subsequently causes the physical server's status to change to marginal which finally cause the status of resource pool's to change to marginal.
A commonly-used solution in the relational database systems is to use relational database triggers such as Standard Query Language (SQL) triggers. SQL Triggers are standardized as part of American National Standards Institute (ANSI) ANSI/ISO/IEC 9075-2:2003, Information Technology, Database languages: SQL. Database triggers are used to propagate the health upwards to dependent database entities. There is one major problem with using this approach which if the trigger uses the old and new health status for the changed entity (i.e. a fibre-channel port), that is not enough information to determine if the parent entity (i.e. a fibre-channel switch) needs to have its health status changed.